home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1832 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.4 KB
  1. Path: colossus.holonet.net!russell
  2. From: russell@news.mdli.com (Russell Blackadar)
  3. Newsgroups: gnu.g++.help,comp.lang.c++
  4. Subject: Re: Argument matching
  5. Followup-To: gnu.g++.help,comp.lang.c++
  6. Date: 13 Jan 1996 02:31:04 GMT
  7. Organization: HoloNet National Internet Access System: 510-704-1058/modem
  8. Distribution: world
  9. Message-ID: <4d75h8$og7@colossus.holonet.net>
  10. References: <9601111542.AA05990@crypt5.cs.uni-sb.de>
  11. NNTP-Posting-Host: jubal.mdli.com
  12. X-Newsreader: TIN [version 1.2 PL2]
  13.  
  14. Stefan Neis (neis@cs.uni-sb.de) wrote:
  15. :                Hi there,
  16.  
  17. : I'm having an ugly problem with templates and inheritance. I mirrored
  18. : my problem by a less complicated --though useless --  example which
  19. : avoids using templates.
  20. :    A    B
  21. :     |
  22. :        Bderived
  23. : and let there be a constructor which makes a Bderived from A.
  24. :
  25. : I hoped, the compiler would automatically convert A to Bderived (user
  26. : defined conv.) and then convert this to B (standard conversion, isn't
  27. : it?) if I give an "A" as argument to a function expecting a "B".
  28.  
  29. Strictly speaking, it expects a const B&, and yes, you can call such
  30. a function with a temporary Bderived as argument.  The trouble is,
  31. *any* class derived from B has this property.  What kind of object
  32. should the compiler construct?  I know, in your example, the situation
  33. is unambiguous, but that won't be true in general.  Your explicit cast
  34. works because it tells the compiler you want, specifically, a
  35. Bderived object. 
  36.  
  37. : I hoped, the compiler would automatically convert A to Bderived (user
  38. : defined conv.) and then convert this to B (standard conversion, isn't
  39. : it?) if I give an "A" as argument to a function expecting a "B". But
  40. : this is obviously not the case -- neither with g++ nor with CC -- (see
  41. : the following example), so I assume that a user defined conversion
  42. : always has to be the last conversion that is applied to an
  43. : argument. Is this assumption correct (Couldn't find anything on this
  44. : in Stroustrup's "The C++ Programming Language")? 
  45.  
  46. Not quite.  It's true when the conversion is via ctor, because of the
  47. potential ambiguity I mention above.  But, for example, if you have
  48. defined an A::operator int(), then it's legal to use an A where
  49. where float is expected.  The conversion to float happens after the
  50. conversion to int. 
  51.  
  52. If so, are there
  53. : plans to change this? I would find this kind of conversions extremely
  54. : useful for using templates, e.g. (to get to my original example) if
  55. : you want a "vector<int>" and a "vector<complex>", where complex is
  56. : intended to be some class realizing complex numbers, you would like to
  57. : have a automatic conversion from "vector<int>" to "vector<complex>"
  58. : and maybe "vector<complex>" should have additional functions. So I
  59. : wrote a "base_vector<T>" (corresponding to B) where all common
  60. : functions are included, vector inherits from this, and is specialised
  61. : for complex...
  62.  
  63. Your idea (or something like it) has considerable merit, if you
  64. derive the template from a base class that is *not* a template.  In
  65. other words, if there is functionality that any vector<T> will share
  66. regardless of T, put it in the base class and you'll get only one
  67. copy of the code generated, instead of a bazillion.  In any case,
  68. you'll need to define the operators all at the vector<T> level, so
  69. that the argument and return types are right -- but probably many
  70. can be one-liners that invoke workhorse functions in the base class.
  71.  
  72. Good luck!
  73.  
  74. [code example deleted]
  75.  
  76. --
  77. Russell Blackadar,   russell@mdli.com
  78.